Various operating systems differ in their implementation of multi-tasking. Such differences may necessitate re-writing of an application when moving an application from one operating system to another. One such difference is whether a task namespace, for variable, is private to a task or is shared among all active tasks in the operating system.
Referring to FIG. 1, a block diagram of a Unix operating system 110 providing multitasking according to the conventional art is shown. As depicted in FIG. 1, a plurality of instances of an open source application 120, 130, task, process, or the like, may be executing simultaneously with each other. Each instance of the application 120, 130 will have a private namespace 140, 150. Thus, the highest scope of a variable and/or function is limited to the application, task, or process level.
In Unix, a namespace is created for each application, which is separate from other application namespaces. As a result, each instance of an application has its own copy of a global variable. A particular global variable is only visible to the process that declared it. Applications are not allowed to read or write to the namespace of another application.
Therefore, a plurality of users can each run an instance of an application simultaneously. Each instance of the application will have a namespace associated with the particular instance of the application. Thus, for example, each user will receive back the result corresponding to their respective input.
Referring now to FIG. 2, a block diagram of a VxWorks operating system 210 providing multitasking according to the conventional art is shown. As depicted in FIG. 2, a plurality of instances of an open source application 220, 230, task, process, or the like, may be executing simultaneously with each other. Each instance of the application 220, 230 will share a common namespace 240. Thus, the highest scope of a variable can be the whole operating system. As a result, an application written in open source for Unix will not run properly if simply compiled to operate in VxWorks.
In VxWorks, a global variable, function and the like, are visible to all applications, tasks, processes and the like running on the system, even if it is a copy of the same task (e.g., two copies of a telnet protocol, a secure shell protocol, or the like). Multiple copies of a variable and/or function are not created. Therefore, multiple instances of the application all use the same variable and/or function, and hence the same namespace. The memory space, providing for the namespace, is rewritten over by each user.
Hence, multiple instances of unmodified open source code will not run properly in VxWorks. For example, each user will receive the result corresponding to the most recently entered input, even though there is distinct results for each user's input.
Referring now to FIG. 3, a flow diagram of a method of porting an open source application to a VxWorks operating environment, according to the conventional art, is shown. As depicted in FIG. 3, the method comprises receiving an open source application, at step 310. The open source application is partially or full re-written, at step 320. Thereafter, the application is operable in a VxWorks operating system environment, at step 330.
Porting code from a Unix operating system to a VxWorks operating system is problematic. The prior art method of changing a program in order to run it in a different operating environment, such as from Unix to VxWorks, is disadvantageous in that the software code of the application needs to be fully or partially re-written. As a result, most of the application has to be rewritten to conform to VxWorks. All the code to be ported from Unix to VxWorks has to be re-written resulting in extensive changes. Hence, a large number of man-hours are spent re-coding. Deficiencies in the re-coding may also result in failure of certain features.
Thus, there is a need for an improved method of porting an open source application to work in a VxWorks operating environment. The method should substantially reduce the amount of code that needs to be re-written.